五一假期后的第一场 TGIP-CN 的直播，继续由郭斯杰大佬为我们带来关于「Deep dive into authentication and authorization」相关内容。
首先回顾一些最近一周 Pulsar 的相关进展：
1. Pulsar 2.5.2 版本即将发布，敬请期待
2. 新增 PIP-63: Readonly Topic Ownership
https://github.com/apache/pulsar/wiki/PIP-63%3A-Readonly-Topic-Ownership-Support
3. 5 月 26 日，将由 Nutanix 的 Shivji Kumar Jha 带来关于「Lessons From Managing A Pulsar Cluster」的线上研讨会。
如果你想参与此活动，可以通过以下链接进行申请，当然也可以期待后续的视频回放。
https://us02web.zoom.us/webinar/register/2015887356422/WN_gZqEn6KTRu25wh4d36bdCw
接下来就一起看看关于认证和授权的相关细节吧！
认证和授权的概念
Pulsar 里的授权机制一直围绕着「Role token」进行，这个角色是任意的一串字符，用来标示“连接到 broker 时所代表的信息”。那如何知道目前连接的信息用户是谁呢？这里就用到了 Authentication Provider。
这是一个认证机制的插件，通过配置插件来判断连接过来客户端的角色。Role 一旦通过认证，就会再通过授权机制来判断此角色是否有相应权限。
关于 Authentication Provider 认证方面，Pulsar 提供了很多方式：
- JSON Web Token Authentication
这些的具体细节，在 Pulsar 官网的文档里其实有很多的介绍，大家可以在官网进行查阅。
https://pulsar.apache.org/docs/en/security-overview/ 有了认证后，就可以证明这条链接“你是谁”的问题，而授权机制则是代表了「对于这件事情你有哪些权限」。目前 Pulsar 的授权也是基于插件上进行操作的，默认 Pulsar 授权机制是基于 ZooKeeper 实现的。授权机制相对比较简单，首先需要确认 role token 是否是超级用户 superusers，可以判断是否有全部的权限。
另一个就是 tenant-admin 里，是否对 tenant 下的 namespace 有相应的权限。还有对于某一个 namespace 是否有生产、消费、执行 function 的权限。
正常 Pulsar 结构组织里，必不可少的就是三大件：ZooKeeper、Bookie 和 Broker。Broker 与 ZooKeeper、Bookie 和 ZooKeeper 之间也需要有认证操作。如果 broker 需要暴露出去，那么也就需要 proxy 依靠于 load balancer 出现。所以这就是最基本的拓扑图，可以更清楚的去设定一个认证和授权的配置。在这里有一个环节大家很容易忽略。很多人觉得客户端与 broker 打交道，proxy 与 broker 连接就可以了。但是 broker 与其他的 broker 之间也会进行相连，尤其是在跨机房复制的过程中， 所以也需要进行认证等步骤。在开始配置认证和授权时，会先从 broker 开始。首先要开启认证，然后确认开启认证的插件，即 “Provider=” 后边要填写的内容，认证后需要开启授权以及授权插件的填写。最后 superUserRoles 是要告诉 broker 哪些用户是你的超级用户。
具体关于 broker 端的认证授权代码操作，可以参考视频回放中 29:00-38:10 时间段。Broker 端配置完成后，就需要配置客户端的相关设置了。让客户端将认证的参数等传给 broker，这样 broker 端才能进行它的认证和授权操作。客户端的操作只需配置两个参数`authPlugin=` 和 `authParams=`，即使用 JWT 的认证方式时，会传入的认证参数。这时客户端访问 broker，就可以进行相应地认证和授权了。以上两大部分配置完成后觉得没有问题了，在执行相应命令时发现有“返回 401，没有权限”等相关提示。这是什么问题呢？这是因为 broker 与 broker 之间还有连接的存在。HTTP 的请求会发给任何一台 broker，但是这台 broker 不一定是这条消息的 ownership，所以它就需要跟其他的 broker 互联访问。所以如果你开启了认证，就必须保证 broker 与 broker 之间的通讯也要包含认证操作的。这个 broker 去访问另一个 broker 时，需要带上相应的认证信息，否则这个链接是无法访问的。因此可以看作第二个 broker 是第一个 broker 的 client。
在这里需要配置的一些细节就是 `brokerClientAuthenticationPlugin=` 和 `brokerClientAuthenticationParameters=`，这个跟上边客户端配置的两处是类似的。具体详细代码应用及 proxy 补充细节，可以参考视频回放中 46:30-56:00 时间段。特别注意一点，所有的验证操作在配置时，都需要在服务端和客户端进行相应的操作。所以当你有了前边的清晰架构后，后边再添加其他组件时，就会比较清楚地知道哪些是服务端了。当然除了以上这些组件，可能你的构建结构中还有 function、function worker 等。
Function worker 可以看做是另一组进程。客户端想去访问 function worker 时，是需要开启认证和授权的过程，配置细节与上方 broker 端的配置数据类似，可以举一反三。同样的，如果 proxy 与 funciton worker 连接访问时，也需要在 proxy 配置这些信息。而 Function worker 作为一个元数据代理/服务端，在实际操作中还会创建出 Pulsar function。Function 在执行时要生产和消费消息，所以需要跟 broker 打交道。所以他们之间也需要配置那些信息，但是是借由 function worker 继承而来。具体关于 function 以及 function worker 的认证和授权代码细节分析，可以参考视频回放中 57:00-64:26 时间段。总结来说，对于认证过程的配置，就是要分辨清楚谁是「服务端」，谁是「客户端」。不同端向配置不同的数据类别。如果对于一个服务而言，它既是一个服务端，又是客户端的话，则需要同时配置两种媒介端的数据信息。同时规划好「谁是 superuser」，这些基本就是 Pulsar 认证过程的重点了。
Q：只启用 client 与 proxy 之间的权限认证是不是就可以了？A：不可以，认证可以在 proxy 进行，但是授权不可以在 proxy 进行。本次直播分享了关于 Pulsar 里的认证和授权配置相关，希望大家能通过上文提供的文字重点+视频回放中的细节可以更清楚的理解这两个机制。
想要获取更多关于「authentication and authorization」相关参考，可以查阅 Pulsar 官网的文档或点击「阅读原文」。
https://pulsar.apache.org/docs/en/security-overview/同时如果你有更多想要了解的 Pulsar 话题，也可以去 tgip-cn repo 下提 issues，我们也会选取大家的提议进行相关话题的直播。
https://github.com/streamnative/tgip-cn/issues